GNSS signals (the “Signal-in-Space” segment) are the main interface between a GNSS (“Global Navigation Satellite System”) spatial infrastructure and the various user segments thereof. In this respect, it plays a major part in the performance which will be available to a user in a given environment and use context. This is because performance is the result of the receiving algorithms used (a function of the use context) and of the quality of the signal which reaches the user (affected by propagation conditions).
The spectral and temporal characteristics of the signal, such as carrier frequency, power or modulation (PRN, BPSK, BOC rate) parameters, substantially determine performance in terms of interoperability, tracking and interference and multipath robustness, etc.
The navigation message itself is also a predominant factor in performance. It determines the services in terms of content, but also, by means of its structure, in terms of availability (robustness) and latency (or responsiveness). The navigation message contains, inter alia, a set of ephemeris and clock correction data (“DECH”) from the transmitting satellite. The set of DECH is taken to mean a set of data sufficient to permit the receiver to compute the satellite position and the satellite clock error. The navigation message makes a significant contribution to acquisition performance, in particular to acquisition time (also known as “Time To First Fix”).
However, the design of a GNSS signal and its navigation message are also the result of a compromise between the various intended service requirements and content (for example and for Galileo: Open Service (OS), Safety of Life (SoL), Search And Rescue Return Link Message (SAR RLM), etc.), sometimes conflicting performance objectives (responsiveness and robustness), and operational or technological constraints (interoperability, mass/consumption/volume of the satellites, etc.).
The Galileo E1 OS and GPS L1C signals thus incorporate numerous changes in comparison with the GPS C/A signal: new navigation message structure, PRN code, optimized modulation schemes, etc. Both signals are directed inter alia towards open service, essentially intended for consumer receivers, and often operate in a difficult environment (urban canyon, for example). However, these two signals differ significantly in their design: the L1C GPS signal is solely directed towards open service, whereas the Galileo OS signal was designed both to handle open service and to supply real-time integrity data (SoL) and the SAR return link channel (SAR RLM). As a consequence, the Galileo message does not solely contain items of ephemeris and time (clock correction) data, but also additional items of data.
It will be noted that the synchronization data broadcast in the navigation message in particular from the Galileo Open Service (Galileo OS) suffer from a lack of robustness. Since this information is necessary for calculating the position of the receiver, the low level of robustness adversely affects the performance of Galileo receivers in terms of acquisition threshold, in particular in “difficult” environments, such as urban canyons or inside buildings.